home *** CD-ROM | disk | FTP | other *** search
/ AMIGA PD 1 / AMIGA-PD-1.iso / NetBSD / docs-netbsd / Mailinglist-Archive / 1994-08.gz / 1994-08 / 000162_owner-current-u…s.berkeley.edu_Thu Aug 4 01:32:28 1994.msg < prev    next >
Text File  |  1994-10-16  |  2KB  |  36 lines
  1. From: der Mouse <mouse@Collatz.McRCIM.McGill.EDU>
  2. To: current-users@sun-lamp.cs.berkeley.edu
  3. Subject: Re: how to concatenate disks
  4. Sender: owner-current-users@sun-lamp.cs.berkeley.edu
  5.  
  6. >> [the following should probably be in some sort of FAQ, so people
  7. >>  don't have to go to the 'source', as i did.]
  8.  
  9. >> How To Concatenate Disks
  10. >> --- -- ----------- -----
  11.  
  12. > No, it should be a man page.
  13.  
  14. Preferably, but I'd take a doc file over nothing.
  15.  
  16. However, I'm curious.  What's machine-dependent about this sort of disk
  17. trickery?  More specifically, why is the ccd stuff everyone is talking
  18. about in the hp300 port, rather than over in some machine-independent
  19. part of the kernel?  I can't see anything conceptually difficult about
  20. a disk driver that just parcels out I/O requests to other drivers (set
  21. via ioctls, perhaps), and while it may not be easy, I don't see any
  22. reason why a machine-specific version of it would be any easier.  (I
  23. tried to do something very similar once under pre-Reno 4.3, and never
  24. got it to work reliably.)
  25.  
  26. Ideally, I'd like to see a disk driver that turns around and reflects
  27. I/O requests back to a user process, which can stripe or interleave or
  28. whatever else it feels like.  (Efficient?  Who said anything about it
  29. being efficient?  I suspect it would be at least usably fast....)  I'd
  30. even write it myself, but if the concatenated disk driver is
  31. machine-dependent, there is clearly magic I don't understand going on
  32. somewhere.
  33.  
  34.                     der Mouse
  35.  
  36.                 mouse@collatz.mcrcim.mcgill.edu